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Volunteering  Information  -  Enhancing  the 
Communication  Capabilities  of  Knowledge-Based  Systems 

Gerhard  Fischer  and  Curl  Slevens 


Department  of  Comouter  Science  and  Institute  ot  Cognitive  Science 
University  of  Colorado,  Campus  Box  430 
Boulder,  CO  80309 


Abstract 

Cooperative  problem  solving  systems  support  the  solution  of  tasks  which  cannot  be  solved  by  tne  human 
or  the  computer  alone.  These  systems  need  to  be  knowledge-based  and  require  flexible  communication 
paradigms  allowing  natural  communication  with  both  experts  and  novice  users  of  the  system.  Natural 
communication  (quite  different  from  natural  language)  has  to  support  mixed-initiative  dialogues  where 
information  can  be  volunteered  by  the  system  and  the  user. 

In  this  paDer,  we  present  prototypical  systems  which  assist  users  in  rebooting  a  computer.  rebcoter  is  a 
rule-based  system  which  guides  the  user  with  a  strongly  system-directed  dialogue  through  this  task.  The 
use  ot  this  system  has  shown  that  the  communication  paradigm  was  too  narrow  to  make  it  a  wonhwnile 
tool  (especially  lor  the  expert  user).  The  systems  assistant  tries  to  overcome  the  noted  shortcomings  by 
allowing  the  users  to  interact  with  the  system  in  a  mixed-initiative  dialogue,  to  volunteer  information  and  to 
deviate  (rom  tne  system  generated  discourse  structure. 


1.  Introduction 

Cur  goal  is  to  establish,  both  by  theoretical  work  and  by  build¬ 
ing  prototypical  systems,  the  scientific  foundations  for  the  con¬ 
struction  of  intelligent  systems  which  serve  as  amplifiers  of 
human  capabiiilies  and  skills.  A  prerequisite  for  intelligent  sys¬ 
tems  is  that  we  understand  the  information  processing  pos¬ 
sibilities  and  limitations  of  the  human  and  the  computer.  Our 
systems  should  not  only  be  significant  as  technical  achieve¬ 
ments  in  computer  science,  but  also  because  they  are  based 
upon  principled  analyses  of  how  one  can  best  help  people  to 
cope  with  complex  information  systems. 

Knowledge-Based  Systems  (KBS)  and  Human-Computer  Com¬ 
munication  (HCC)  are  two  crucial  research  areas  tor  these 
goals.  We  are  especially  interested  in  understanding  the  pos¬ 
sibilities  of  pursuing  these  two  research  areas  together.  The 
rationale  tor  this  approach  is  that  on  the  one  hand  effective 
human-computer  communication  is  more  than  creating  attrac¬ 
tive  displays  on  a  CRT  screen:  it  requires  providing  the  com¬ 
puter  with  a  considerable  body  of  knowledge  about  the  world, 
about  users  and  about  communication  processes  (Fischer  83). 
On  the  other  hand  the  use  of  knowledge-based  systems  will  be 
severely  limited  if  we  are  unable  to  elimin-  (he 
communication  bottleneck. 

Alter  characterizing  general  communication  paradigms,  this 
paper  examines  one  aspect  ot  this  approach,  the  design  of 
knowledge -based  systems  and  their  communication 
capabilities  to  allow  the  volunteenng  of  information  by  the  user 
of  the  system.  Being  able  to  volunteer  information,  users  ot  a 
knowledge-based  system  are  no  longer  at  the  mercy  of  an  un¬ 
seen  reasoning  component  that  dictates  the  order  in  which  in¬ 
formation  is  absorbed  by  tne  system.  When  combined  with  a 
data  driven  rule  base,  users  are  ottered  an  opportunity  to 
actively  use  a  system  and  direct  it  according  to  their  goals. 
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2.  Communication  Paradigms  in  Knowledge- 
Based  Systems 

The  use  ot  knowledge-based  systems  will  be  severely  limited  it 
we  are  unable  to  eliminate  the  communication  bottleneck.  The 
main  reason  that  knowledge-based  systems  have  not  moved 
beyond  the  research  state  has  pnmarily  been  their  limited  com¬ 
munication  capabilities  (an  example  being  the  mycin  system 
[Buchanan,  Shortlifle  84]).  The  analysis  ot  the  oipmeter  sys¬ 
tem  [Smith  84]  has  revealed  that  the  user  interlace  portion  is 
the  largest  part  (42  percent)  ot  a  knowledge-based  system. 

In  this  section,  a  framework  for  different  communication 
capabilities  is  illustrated  by  defining  "natural  communication'' 
and  "mixed-initiative  dialogues”,  characterizing  different  sys¬ 
tem  architectures  depending  on  the  distribution  of  the 
speaker/listener  role  and  discussing  architectures,  require¬ 
ments  and  examples  ior  systems  which  allow  the  system 
and/or  the  user  to  volunteer  advice 

Natural  Communication.  Natural  Communication  is  more 
than  me  ability  to  communicate  in  natural  language.  It  is  me 
ability  lo  engage  in  a  dialogue  and  when  humans  (e  g.,  a 
novice  and  an  expert)  communicate  much  more  goes  on  than 
just  ihe  request  for  factual  information.  Novices  may  not  be 
able  to  articulate  their  questions  without  the  help  of  the  expert, 
the  advice  given  by  the  expert  may  not  be  understood  and/or 
the  advisee  may  request  an  explanation  ol  it:  each  communica¬ 
tion  partner  may  hypothesize  mat  me  other  partner  misun¬ 
derstood  him/her  or  they  may  provide  information  which  they 
were  not  explicitly  asked  for. 

Natural  Communication  needs  the  right  kind  of  user  interlace  to 
support  it.  but  it  cannot  be  restricted  lo  tust  the  user  interface 
The  underlying  knowledge  base  must  contain  the  needed 
knowledge  and  it  must  be  structured  in  the  right  way. 
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Despite  the  tact  that  communication  capabilities  such  as 
mixed-initiative  dialogues  [Carbonelli970a|  have  been  found  to 
be  crucial  for  intelligent  systems,  the  progress  to  achieve  them 
has  been  rather  modest.  Limited  natural  language  interfaces 
have  often  overshadowed  the  real  shortcomings.  The  mycin 
sys 'em  and  the  rebooted  (see  section  3)  serve  as  good  ex¬ 
amples:  they  are  based  on  the  consultation  model .  From  an 
engineering  point  ot  view,  this  model  has  the  advantage  of  be¬ 
ing  clear  and  simple:  the  program  controls  the  dialogue  (much 
as  a  human  consultant  does)  by  asking  for  specific  items  of 
data  about  the  problem  at  hand.  The  disadvantages  are  that  it 
prevents  the  user  from  volunteering  relevant  data  and  it  sets  up 
the  program  as  an  “expert",  leaving  the  user  in  the  undesirable 
position  ot  asking  a  macnine  lor  help. 

The  Speaker  versus  the  Listener  Role.  Based  on  the 
asymmetry  between  human  and  computer,  the  design  of  the 
communication  between  humans  and  computers  is  a  problem 
not  only  of  simulating  human-to-human  communication  but  of 
engineering  alternatives  in  the  domain  of  interaction-related 
properties  (Bolt  84).  Natural  language  should  not  be  used  for 
every  application;  in  many  cases  it  is  not  the  preferred  mode  ot 
communication  (Bates.  Boorcw  84). 

Communication  can  be  described  in  terms  of  the  speaker  and 
the  listener  roles.  The  speaker  presents  information  (e.g.,  in  the 
form  of  a  question  or  as  a  request  for  action)  which  the  listener 
tnes  to  understand.  It  is  often  difficult  to  determine  which  role 
suits  which  agent  best.  We  have  argued  that  the  listener  role  is 
always  the  more  diflicult  one  [Fischer  86],  because  the  listener 
has  to  understand  the  problem  based  on  the  speaker's  descrip¬ 
tion. 

Natural  language  interfaces  are  desirable,  because  the  human 
is  the  speaker  and  can  talk  in  her/his  terms  about  a  problem. 
Unfortunately  this  kind  of  natural  language  interface  does  not 
exist.  The  user  is  either  forced  to  answer  questions  in  simple 
terms  or  to  team  to  adapt  to  the  limited  natural  language  under¬ 
standing  capabilities  ot  the  system,  in  form-based  systems,  the 
system  has  the  role  of  the  speaker  and  it  shows  its  understand¬ 
ing  ot  the  world  to  the  user.  Our  work  has  been  primarily 
guided  by  the  belief  that  the  user  is  more  intelligent  and  can  be 
directed  into  a  particular  context;  this  is  why  most  ot  our  inter¬ 
laces  are  form-based. 

Computer  Systems  volunteering  advice.  Humans  often 
learn  by  receiving  answers  to  questions  which  they  have  never 
posed.  For  example,  if  they  see  a  sign  that  says  “Snow  Tires 
Or  Chains  Required  Beyond  This  Point ",  they  have  learned 
many  things.  They  know  that  there  is  probably  snow  ahead  on 
the  road  and  that  they  can  buy  snow  tires  to  eliminate  the  need 
lor  chains.  This  information  is  volunteered  -  there  is  no  need  to 
ask  lor  it. 

To  ask  a  question,  one  must  know  how  to  ask  it.  and  one  can¬ 
not  ask  questions  about  knowledge  wnose  existence  is  un¬ 
known.  We  have  developed  programs  (e  g.,  the  active  help 
system  activist  (Fischer,  Lemke.  Schwab  85]  and  the 
usP  CBiTtc  (Fischer  87]),  wnich  volunteer  information  and  sup¬ 
port  the  acquisition  of  information  by  chance,  activist  looks  a 
user  (working  with  an  editor)  “over  the  shoulder",  inters  from 
user  actions  the  plan  which  the  user  wants  to  achieve  and 
compares  it  with  its  own  plan.  Information  about  the  conjec¬ 
tured  knowledge  is  stored  in  the  model  ot  the  user.  A  separate 
tutonng  module  decides  when  to  of  ter  helo  and  advice.  The 
lisp-critic  enhances  incremental  learning  of  lisp  and  supports 


learning  strategies  such  as  learning  on  demand,  it  has 
knowledge  about  how  to  improve  lisp  programs  locally,  follow¬ 
ing  a  style  as  defined  by  its  roles.  The  advice  given  is  based  on 
the  hypothesized  knowledge  of  the  user  contained  in  the 
system's  model  of  the  user.  Additional  tools  are  available  to 
explain  and  illustrate  the  advice. 

A  number  of  things  have  been  learned  constructing  these  sys¬ 
tems.  Volunteered  advice  is  most  welcome  it  it  is  directly 
relevant  ;c  ihe  prcolem  oi  the  task  the  user  is  working  on  T.ie 
major  problem  in  systems  of  this  kind  is  not  to  make  them 
speak  up  but  to  keep  them  quiet  most  ot  the  time.  To  eomeve 
this  requires  elaborate  knowledge  structures  (e  g.,  models  ol 
the  users  and  tutorial  strategies).  In  addition,  users  must  have 
the  control  to  ignore  the  volunteered  information  (they  may  al¬ 
ready  i  now  it  or  they  may  regard  it  as  not  relevant)  or  turn  the 
systems  off  altogether. 

Constructing  systems  which  volunteer  information  creates  a 
number  of  interesting  and  challenging  problems.  For  the  rest  ot 
this  paper  we  are  concerned  with  the  opposite  enhancement  to 
communication:  allowing  the  user  to  volunteer  information. 

Users  volunteering  advice.  One  ot  the  major  stumbling 
blocks  in  the  successful  use  of  knowledge-based  systems  is 
the  general  feeling  of  apathy  wah  wnich  many  ol  these  systems 
are  met  by  the  users.  Much  of  the  refusal  to  utilize  systems 
such  as  mycin  and  rebooted  stems  from  the  (act  that  users, 
wtio  otten  think  of  themselves  as  experts,  feel  that  the  system 
is  telling  them  what  to  do.  The  system  asks  a  question  wmcn 
the  user  answers.  The  system  then  decides,  by  some  hidden 
mechanism,  if  it  needs  more  information  or  is  going  to  give  ihb 
user  advice.  At  no  tune  are  the  users  artorded  the  opportunity 
to  make  their  observations  known  to  the  computer.  They  are 
simply  allowed  to  answer  the  questions  put  to  them  -  a  role 
which  most  humans  do  not  expenence  as  very  satisfying.  An 
expert  who  is  knowledgeable  about  a  domain  wants  to  take  an 
active  role  in  the  process  ol  deciding  what  actions  should  be 
taken.  While  cooperative  advice  or  criticism  from  a  computer  is 
welcome  (e  g.,  Ike  in  the  systems  described  above),  the  typical 
knowledge-based  system  that  forces  a  particular  format  ot  dis¬ 
cussion  upon  the  user  is  not. 

The  gus  (“Genial  Understanding  System")  system  (Bobrow  et 
at.  77|attempted  to  model  a  natural  dialogue  and  it  could  cope 
with  volunteered  information.  This  was  achieved  by  selecting  a 
narrow  domain  (assisting  the  user  in  planning  a  trip)  which  con¬ 
strained  the  range  ot  expectations  that  3us  needed  to  have 
about  the  user's  plans.  The  system  was  driven  by  a  number  ot 
frames  which  characterized  the  domain  and  the  dialogue  itseit 

Our  contribution  to  increase  the  naturalness  of  communication 
and  to  eliminate  some  ol  the  inflexibility  is  the  introduction  of 
mechanisms  which  allow  the  user  to  volunteer  information  to 
the  system.  We  will  lirst  describe  rebooter.  an  conventional 
knowledge-based  system  which  we  have  built,  used  and 
evaluated.  The  shortcomings  of  rebooter  led  to  the  develop¬ 
ment  ot  the  systems  assistant,  which  is  an  illustration  that  en¬ 
hanced  communication  capabilities  are  of  crucial  importance 
for  knowledge-based  systems. 
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3.  rebooter:  a  Knowledge-Based  System  to 
Reboot  Computers 

Problem  Description,  rebooter  is  a  knowledge-based  sys¬ 
tem  which  allows  users  to  reboot  a  pyramo  sox  computer  alter 
it  has  crashed.  It  has  a  set  of  predetermined  tasks  wnich  drive 
it  to  ask  lor  certain  pertinent  information.  U  the  user  goal  is  to 
reboot  the  machine,  rebooter  first  tries  lo  get  the  machine 
running.  When  a  certain  state  has  been  reached,  the  system 
will  instantiate  the  task  to  boot  the  machine  into  single-user 
mode,  and  finally  into  multi-user  mode.  This  process  consists 
of  five  major  tasks  which  are  the  initial  status  check  (is  the 
power  on  and  can  you  log  in),  error  recording,  booting,  file¬ 
system  checking,  and  bnnging  the  machine  into  multi-user 
mode.  Examples  of  these  tasks  are  in  Figure  3-1  and  a  sample 
session  with  rebooter  is  described  in  Figure  3-2. 


•  Status  Query  Task:  This  task  starts  (he 
rebooter  by  asking  about  the  power  and  login 
status  of  the  machine. 

•  Reseat_boards  Task:  This  task  may  be  initialed 
when  there  has  been  a  problem  rebooting  the 
machine,  the  machine  is  up  and  a  network 
problem  has  been  lound,  or  the  rebooter 
susoects  that  a  nrobtem  mav  be  caused  by  a 
board  being  misaligned  on  the  bus.  Making  sure 
the  boards  in  the  machine  are  seated  property  of- 
len  solves  these  problems. 

•  Dlagnose_noboot  Task:  There  are  indications 
that  there  is  an  error  in  the  booting  process  and 
further  steps  will  be  necessary  to  bring  the 
machine  back  up  (it  is  inside  the  Diagnose _Noboot 
task  where  the  most  sophisticated  roles  reside). 

Figure  3-1:  Task  Examples 


The  initial  status,  error  recording,  file-system  checking,  and 
multi-user  tasks  are  role  sets  that  ask  basic  questions  (e  g.,  are 
there  arty  error  messages  on  the  console)  or  require  simple 
actions  (e.g..  please  record  any  error  messages  n  the  log 
book).  Inside  the  booting  task  are  a  number  of  sub-tasks.  This 
is  where  the  interesting  roles  reside  and  the  data-driven 
paradigm  is  put  to  the  test.  It  is  inside  this  task  where  diagnosis 
of  failed  reboot  attempts  is  earned  out.  The  roles  here  help 
users  determine  what  causes  this  failure.  While  automatic 
rebooting  options  are  available,  they  are  not  able  to  deaJ  with 
problems  like  hardware  failures  and  serious  file  system  errors. 
In  these  cases  the  macriine  will  tail  its  attempts  at  reboot  or  will 
simply  tell  the  operator  that  tile  system  checking  must  be  done 
manually.  Unlortunaiely.  experience  snows  that  these  con¬ 
ditions  occur  more  often  than  we  would  like.  Rebooting  a  com¬ 
puter.  especially  it  the  person  is  not  totally  familiar  with  it,  is  a 
non-trivial  problem.  This  is  demonstrated  by  the  fact  that  2  to  6 
months  of  on  the  job  framing  are  done  by  our  novice  systems 
administrators  before  they  are  confident  enough  lo  reboot 
machines  on  their  own.  A  computer  is  a  complex  and  expen¬ 
sive  pieco  ol  equipment  wmen  requires  a  lot  of  intuitive 
knowledge  to  deal  with  on  an  administrative  basis.  The  reboot¬ 
ing  process  ranges  from  the  trivial  pressing  of  a  couple  ot  keys 
on  the  console  lo  the  complicated  task  ot  diagnosing  hardware 
failures,  rebooter.  designed  specifically  to  help  with  this 
process,  can  significantly  reduce  the  complexity  of  this  task.  At 
(he  same  time,  it  allows  users  to  slowly  incorporate  this  intuitive 
knowledge  mio  their  own  knowledge  structures  by  making  tnem 


familiar  with  the  types  ol  actions  necessary  to  perform  this  task. 

Through  our  experience  in  rebooting  comp  ters.  rebooters 
contribution  to  the  work  ot  a  novice  systems  employee  is  ob¬ 
vious.  Novices  simply  do  not  know  how  to  accomplish  this 
task.  They  need  to  communicate  with  an  expert  to  achieve  their 
goal.  Similarly,  while  expens  can  usually  deal  with  rebooting 
problems,  they  often  seek  advice  from  other  experts  to  confirm 
or  enhance  their  understanding  ol  those  problems.  Just  as 
another  pair  ol  eyes  can  often  uncover  hidden  bugs  in  a 
program,  communication  dunng  the  diagnosis  of  a  reboot  can 
often  yield  more  useful  plans  ol  action,  rebooter  helps  till  this 
rote. 

The  Krtow.edge  Base.  Tho  knowledge  Case  ct  the  rebooter. 
which  exetudes  the  user  interface,  consists  of  a  set  ol  OPS5 
production  roles  [Brownston  et  aL  85].  The  inference 
mechanism  used  is  forward  chaining  which  leads  the  structure 
ol  the  roles  to  be  in  a  task  based,  data-driven  paradigm.  The 
rules  themselves  decide  when  it  is  appropriate  to  switch  from 
one  task  to  another.  Tasks  are  instantiated  based  on  what  the 
previous  tasks  were  able  to  find  out  or  accomplish.  The 
program  has  two  main  modules,  domain  knowledge  and  ex¬ 
planation.  Each  module  consists  ot  several  tasks,  some  of 
which  are  listed  in  Figure  3-1  for  the  domain  module.  Tasks 
consist  oi  several  ruies  related  through  the  domain  knowledge 
they  analyze,  and  they  comprise  a  question  and  answer  ses¬ 
sion  that  guide  both  the  user  and  rebooter  through  the 
problem  space.  A  limited  explanation  module  performs  a  post¬ 
analysis  on  the  working  memory  elements  ten  by  the  session 
and  outputs  its  results,  in  the  form  ol  canned  text,  to  a  tile 
which  the  user  can  then  consult. 

Communication  Capabilities  ot  rebooter.  rebooter’s  user 
interlace  is  a  text  based  dialogue  session  that  runs  on  tradi¬ 
tional  CRT  terminals,  rebooter  presents  a  senes  ol  questions 
that  lead  Ihe  user  through  the  five  major  tasks  necessary  to 
reboot  the  computer.  As  the  dialogue  session  progresses. 
rebooter  s  knowledge  base  evolves  through  states  which  lire 
Ihe  necessary  tasks  in  each  of  these  live  categories.  A  typical 
session  with  rebooter  that  represents  a  troubie-lree  reboot  is 
reproduced  below  (see  Figure  3-2). 

This  represents  a  system  with  traditional  communication 
capabilities.  Users  are  only  allowed  to  answer  questions  that 
are  put  to  them  by  rebooter.  The  system-driven  dialogue 
session  keeps  the  user  in  a  passive  role  with  respect  to  deci¬ 
sion  making  in  the  reboot  process.  A  graphical  description  ot 
this  type  oi  communication  is  in  Figure  3-3. 

Shortcomings  of  rebooter.  rebooter  was  out  into  use  by 
the  systems  statt  lor  a  snort  period  ot  time  dunng  when 
shortcomings  in  its  design  became  apparent.  Observations 
and  discussions  with  users  ot  the  system  yielded  interesting 
results.  While  novice  users  are  quite  comfortable  with  the 
system-driven  dialogue  paradigm,  expert  users  are  quite  ir¬ 
ritated  by  it.  In  tact,  expert  users  refused  to  use  the  system 
after  their  lirst  or  second  expenence  with  it.  Discussions  with 
Ihe  various  users  clearly  indicated  that  experts  do  not  want  to 
be  forced  into  a  particular  forma!  ot  discussion  with  a  system, 
while  novices  gain  confidence  in  their  actions  through  this  very 
same  mechanism. 

Similar  reactions  were  observed  when  the  mycin  (Buchanan. 
Shorfliffe  84)  program  was  introduced  into  the  medical  es¬ 
tablishment.  When  experts  in  a  held  use  a  knowledge-based 
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INITIAL  QUERY:  Is  the  machine' s  power  turned  on? 
«yes/no»  yes 

Can  you  log  on  to  the  machine  that  is  down 
across  the  network?  «yes/no>>rc 
Can  you  log  on  to  the  machine  that  is  down  at 
the  console?  <<yes/no»no 

ERROR  RECORDING  Record  any  error  messages  that 
appear  on  the  console.  Go  to  the  £_Fraoe  by 
pressing  HOME  then  E.  Are  there  any  flashing 
error  codes?  «yes/no»  no 

BOOTING:  Go  to  the  System  Configuration  Frame 
(Frame  1)  by  pressing  HOME  then  1.  Press  b 
then  z  to  boot  the  machine  and  start  the  CPU . 
Do  the  two  windows  at  the  bottom  right  comer 
of  the  console  report  that  the  machine  is 
BOOTED?  «yes/no»yes 
that  the  CPU  is  RUNNING?  «yes/no»yeS 

SINGLE  USER  MOOE:  . 

SET  THE  DATE . 

FILE  SYSTEM  CHFCK:  . 

MULTI  USER  MOOE:  To  go  into  Bulti_user  mode  press 
*D  (control_D) 

Execution  halted  by  rule:  multi_user_mode . 
Mould  you  like  an  explanation  of  the  session? 
<<yes/no»  yes 

ir  YOU  GENERATED  AN  EXPLANATION  IT  MILL  BE 
FOUND  IN: 

/staff /system/ stevens/ reboots r/RULETRACE 
THANKS  FOR  USING  REBOOTER.  MAIL  ANY  COMMENTS 
TO  CURT. 

Figure  3-2:  A  Panlai  Session  with  REBOOTER 


Figure  3-3:  Control  Flow  in  a  System-Driven  Dialogue 


system  Ihey  need  to  leel  that  they  have  an  active  role  in  the 
process  of  deciding  what  actions  should  be  taken,  in 
REBOOTER,  the  dialogue  is  eompleiely  system-oriven.  Users  are 
delegated  the  tasks  of  answering  questions  and  pushing  but¬ 
tons.  mycin  has  the  very  same  problem.  Users  are  put  in  a 
passive  role  througnout  iheir  interaction  with  the  system. 

In  Ihe  real  world  there  are  many  instances  ol  systems  which,  il 
implemented,  must  exhibit  the  properly  that  users  can  im¬ 
mediately  locus  the  attention  ot  the  system  For  example,  take 
a  system  that  serves  as  an  auto-piiot  lor  an  aircraft  II  pilots 
observe  something  that  involves  an  implied  time  constraint, 
they  must  have  the  ability  to  communicate  this  information  to 
the  system.  Without  this  llexibilily  the  system  can  never  be 
used. 


4.  The  SYSTEM’S  assistant:  Incorporating 
Information  Volunteering 

Our  solution  to  this  problem  ot  inflexibility  in  the  communication 
paradigm  is  the  introduction  ot  a  mechanism  through  which  the 
user  can  volunteer  information  to  the  system.  By  volunteering 
information  we  mean  that  the  user  can  make  statements  about 
the  domain  which  are  out  of  context  with  respect  to  the  current 
conversation  between  user  and  system,  imorrraldn  volunteer¬ 
ing  allows  users  to  be  in  the  speaker  role  and  locus  the  atten¬ 
tion  ot  the  system  on  the  information  whicn  ihey  teel  is 
relevant.  The  user  is  no  longer  jjst  answenng  questions,  but 
taking  an  active  role  in  deciding  what  ihe  knowledge-based 
system  is  reasorung  about.  The  system  now  plays  the  role  ol 
assisting  users  as  opposed  to  directing  users  and  therefore  this 
new  version  ol  our  knowledge-based  system  is  called  me 
systems  assistant  (the  term  systems  assistant  is  derived 
from  Ihe  name  of  the  group  which  maintains  the  computers  m 
the  Computer  Science  department.  The  group  is  called  the 
Systems  Group,  hence  the  name  systems  assistant)  infor¬ 
mation  volunteering  is  probably  best  explained  by  way  ol  an 
example: 

When  a  user  first  starts  up  a  session  with  the 
systems  assistant  the  system  will  always  begin  by 
asking  some  basic  information  about  the  pyraiao  m 
question.  This  information  must  be  known  to  the 
systems  assistant  lor  it  to  bo  any  diagnosis  or  offer 
any  assistance.  Beyond  that  point,  however,  the  ac¬ 
tions  whicn  the  systems  assistant  win  take  are 
mostly  dependant  upon  Ihe  data  which  the  user  sup¬ 
plies  in  response  lo  its  inquiries.  The  systems 
assistant  asks  a  question  alter  which  the  user 
responds  with  some  new  data.  After  reviewing  the 
modified  state  ol  the  data  at  hand  the  systems 
assistant  proceeds  to  suggest  some  course  ol  ac¬ 
tion  which  is  then  earned  out  by  the  user.  This  loop 
(see  Figure  3-3)  continues  until  the  systems 
assistant  has  successfully  helped  the  user  reboot 
the  computer.  However,  an  experienced  systems  ad¬ 
ministrator  will  be  able  lo  nonce  pertinent  inlormanon 
long  before  the  systems  assistant  asks  about  it.  For 
instance,  these  types  ol  users  might  quickly  notice 
that  the  ethemei  board  is  sticking  an  inch  further  out 
than  the  rest  ot  the  boards  <n  the  machine.  They 
would  certainly  come  to  the  conclusion  that  this  might 
have  something  to  do  with  the  machine  s  problem, 
and  therefore  want  lo  locus  the  attention  ol  the 
systems  assistant  on  that  tact.  This  type  ot  infor¬ 
mation  is  considered  out  ot  context  since  the 
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systems  assistant  is  asking  questions  like  is  the 

MACHINE'S  POWER  TURNED  ON.  Qt  DOES  THE  CONSOLE 

say  that  the  cpu  is  Running.  U  users  know  some¬ 
thing  about  the  system,  then  they  should  be  able  to 
present  that  information  to  the  systems  assistant  as 
soon  as  it  becomes  apparent. 


The  systems  assistant  requires  an  extended  model  of  inter¬ 
action  (see  Figure  4-1),  incorporates  a  new  interlace  (see 
Figure  4-2),  and  requires  a  mator  restructuring  ot  the 
Knowledge  base  used  in  rebooted. 

The  system's  knowledge  is  explicitly  represented  in  a  world 
model  with  which  the  user  interacts  in  a  direct  manipulation 
style  [Hutchins,  Hoilan.  Norman  u5).  The  dilterent  hardware 
components  ol  the  pyramid  are  represented  in  graphical  form 
(see  Figure  4-2). 

Users  can  either  ask  lor  general  information  about  each  ol 
these  components  or  volunteer  information  about  them.  II  users 
are  confused  about  what  an  icon  represents  they  can  ask  the 
system  about  that  icon  by  clicking  the  mous'd  on  it.  At  .hat 
point  the  system  presents  the  user  with  a  text  based  explana¬ 
tion  about  the  component  in  question.  II  also  explains  some  ol 
the  most  common  indications  that  this  component  is  damaged 
and  common  methods  ol  determining  the  functional  state  ol  it. 
These  possibilities  give  the  user  a  window  into  the  "mind"  ol 
the  systems  assistant  and  provide  a  well  defined  and  com¬ 
mon  basis  for  communication  between  the  user  and  the  sys¬ 
tem.  To  volunteer  information  (and  change  the  context  in 
which  the  icons  are  understood),  the  users  click  with  the  mouse 
on  the  volunteer  information  icon.  At  this  point  a  click  on  any  ol 
the  machine  component  icons  yields  a  menu  ot  possible  (acts 
about  that  particular  component.  Since  we  are  asking  the  user 
to  volunteer  information  that  is  best  described  by  natural  lan¬ 
guage.  but  are  not  able  to  allow  the  actual  use  ol  natural  Ian- 
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Figure  4-2:  initial  State  Ol  The  systems  assistant 
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guage.  we  present  the  user  with  a  menu  ol  text  based  choices. 
This  menu  delines  lor  the  user  the  possible  space  ot  infor¬ 
mation  which  can  be  understood  by  the  rule  base  ot  the 
systems  assistant.  Figure  4-3  is  a  typical  example  ol  what  one 
ot  these  menus  looks  like.  On  the  lelt  side  are  the  common 
problems  associated  with  this  particular  piece  ol  haroware.  On 
the  right  side  are  the  choices  which  indicate  that  one  ot  (he 
problem  areas  has  already  been  checked,  and  at  the  bottom  is 
a  choice  indicating  an  unfounded  suspicion  that  something  has 
gone  wrong  with  that  piece  ol  hardware.  In  this  manner  the 
user  is  afforded  the  opportunity  to  volunteer  out  of  context  in¬ 
formation. 

The  interlace,  however,  is  not  the  most  crucial  modification  that 
is  necessary.  To  bnng  information  volunteering  to  iruition  it  is 
not  sufficient  to  change  the  external  appearance  ol  the  system 
on  the  screen.  This  new  mechanism  requires  the  restructuring 
of  (he  knowledge  base  lo  accommodate  the  incoming  out  of 
context  information,  in  rebooter,  an  analysis  ol  the  structure 
of  tasks  was  earned  out  to  determine  which  task  should  in  turn 
instantiate  successive  tasks.  The  onginal  design  was  tar  too 
rigid  lor  the  information  volunteering  mechanism.  What  is 
needed  is  a  more  general  methodology  lor  determining  the  cur¬ 
rent  task  selection.  This  problem  is  being  solved  by  removing 
the  task  selection  criterion  from  the  tasks  themselves  and 
creating  an  autonomous  collection  ol  rules  whose  onlv  function 
is  to  recognize  situations  in  which  particular  tasks  should  be 
instantiated.  To  operate  in  this  mode  the  system  needs  more 
information  about  the  machine  components  and  its  own  rule 
groups  than  befom  to  allow  the  systems  assistant  to  resolve 
conflicts  when  more  than  one  task  is  simultaneously  instan¬ 
tiated  due  to  some  volunteered  information.  This  extra 


knowledge  allows  the  systems  assistant  to  be  much  more 
powerful  in  its  ability  to  handle  the  inevitable  context  switches 
that  occur  due  to  the  incoming  out  of  context  information. 

In  addition,  a  mechanism  is  needed  through  which  the  system 
can  determine  what  information  is  implicit  in  the  volunteered 
information.  For  instance,  this  instantiation  ot  tasks  might  be 
altered  if  users  volunteer  information  that  implies  they  have  al¬ 
ready  tried  lo  reboot  the  machine.  A  related  problem  is  the 
decision  ol  whether  to  ask  a  previously  posed  question  again. 
The  volunteered  information  might  have  implied  an  answer  to 
this  earlier  question  and  the  rule  base  has  to  be  general 
enough  to  handle  these  cases. 

5.  Experiences  and  Future  Research 

The  shortcomings  ol  the  rebooter  clearly  indicated  that 
knowledge-based  systems  will  not  be  accepted  if  their  com¬ 
munication  capabilities  are  too  limited.  The  design  and  the  im¬ 
plementation  of  the  systems  assistant  provided  another  piece 
ot  evidence  (along  the  findings  of  the  dipmeter  system  (Smith 
84])  that  designing  the  knowledge  base  and  the  inference  en¬ 
gine  of  a  knowledge-based  system  may  be  a  much  easier  task 
than  providing  these  systems  with  the  right  kind  of  communica¬ 
tion  capabilities.  Making  a  system  able  lo  accept  volunteered 
information  is  not  just  a  matter  ot  redesigning  the  interlace  to 
that  system  but  requires  that  the  knowledge  base  be  enhanced 
and  reorganized. 

The  SYSTEMS  assistant  seems  to  provide  the  right  kind  of  mix¬ 
ture  between  highly  structured  dialogues  (which  are  useful  lor 
the  novice)  and  the  possibility  to  volunteer  information  to  get  to 
the  point  quickly,  which  is  a  necessary  requirement  to  make  a 


BOARD  MISSING  BOARD  RESEATED 

[BOARD  n  UNSEATED)  HARDWARE  ADDRESS  OK. 

BAD  HARDWARE  ADDRESS  SOFTWARE  ADDRESS  OK 

BAD  SOFTWARE  ADDRESS 

UNKNOWN  PROBLEM  SUSPECTED 


WOKUmtcK  IMFOWWtlQW 

..“Me#*#  or  no.. 

row  p reeeoo  in*  TtS  MIM 

Cor,  yaw  >»•  Oft  to  Uw  W*ot  l«  down  Kren  Um  notworit? 

..Mum  enow**-  vet  or  ne.. 

Tow  btm»m  the  rfS  Button 


oocTuno  noMt  T"£— / T* 

pyramid  SOX 


Con  vow  lot  U  tno  nocfiino  tn»t  (a  down  at  tin  conoot •? 


Fuj  j  Eaqla  4100 


..Ftaaao  anawor  ret  «r  no.. 

row  clicMd  on  tno  watunffCt  lirflUfWUOB  loon 

row  tlUfrad  on  tno  uOLuniCCI  If*0*'lHII0n  icon 
_ rr*t  OUT Pul 


GfD 


(JD 


Coaputar  Scianca 


condittani  REBOOTING 


VOLUNTEER  INFORflATION 

BfSWhSI  urnoou 


CMP*  STM1  tfS 


Figure  4-3:  Volunteering  Information  About  The  Ethernet  Controller 


6 


system  acceptable  to  the  expert. 

Many  more  features  should  (and  will  be)  added  to  the  systems 
assistant.  Having  a  sensory  system  (which  signals  the  state 
ot  the  broken  machine)  connected  to  the  systems  assistant 
would  allow  it  to  monitor  the  actions  taken  by  the  user.  Users 
should  also  be  able  to  query  the  system  on  how  or  why  it  does 
anything,  if  the  system  says  that  the  ethemet  board  needs  to 
be  reseated  on  the  bus.  users  might  want  to  know  how  to  do 
this,  or  why  the  system  teels  that  this  is  necessary  (the  second 
question  requires  more  elaborate  explanation  capabilities  than 
most  system  currently  have). 

An  extension  in  another  dimension,  which  is  dosely  related  to 
our  woik  supporting  human  problem  domain  communication 
[FischerLemkei987a|,  is  to  allow  users  ot  the  system  to  create 
their  own  machine  configurations  with  the  assistance  of  con¬ 
struction  and  design  kits. 

It  users  are  not  witling  to  use  the  systems  we  design,  a  major 
component  ot  the  employed  theory  and  methodology  must  be 
missing.  In  many  cases  this  resistance  will  be  based  on  the 
limited  communication  capabilities.  Natural  communication  is  a 
crucial  aspect  to  increase  the  usefulness  and  usability  of  com¬ 
puters.  Information  volunteering  is  an  important  part  of  it  which 
should  be  explored  in  other  task  domains.  Knowledge-based 
systems  ot  all  types  can  benefit  from  allowing  the  user  to  have 
more  control. 
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